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Abstract 

The progressive integration of automation technologies in commercial transport aircraft flight 
decks — the “glass cockpit” — has had a major, and generally positive, impact on flight crew 
operations. Flight deck automation has provided significant benefits, such as economic 
efficiency, increased precision and safety, and enhanced functionality within the crew interface. 
These enhancements, however, may have been accrued at a price, such as complexity added to 
crew/automation interaction that has been implicated in a number of aircraft incidents and 
accidents. This report briefly describes “glass cockpit” evolution. Some relevant aircraft 
accidents and incidents are described, followed by a more detailed description of 
human/automation issues and problems (e.g., crew error, monitoring, modes, command 
authority, crew coordination, workload, and training). This paper concludes with example 
principles and guidelines for considering “glass cockpit” human/automation integration within 
space transportation systems. 


Introduction and Background 

The progressive integration of automation technologies, Flight Management Systems (FMS), and 
enhanced displays in commercial transport aircraft flight decks — the “glass cockpit” — has had a 
major, and generally positive, impact on flight crew operations. For example, these technologies 
have increased safety and have provided enhanced crew interface features and use of limited 
cockpit “real estate,” more efficient flight path control and management, and a general reduction 
in crew workload. 

It is anticipated that significant automation technologies will be considered for integration into 
the next generation reusable human-rated space transportation system. This automation has the 
potential to enhance such functions as launch, ascent, and orbit insertion; rendezvous and 
proximity operations (e.g., during ISS resupply missions, for satellite retrieval and repair); 
detection and actuation of escape systems; on-orbit payload operations; and de-orbit, entry, 
descent, approach, and landing (especially with a deconditioned crew). Automation has 
provided a number of benefits on aircraft flight decks and could provide similar benefits to a 
Reusable Launch Vehicle (RLV). Some of these benefits are: 

• Economic Efficiencies: Automation has provided savings in a number of 
domains, by enhancing efficiencies (e.g., in fuel use) and by reducing 
operating costs (e.g., by enhanced reliability, reduced maintenance 
requirements, and reduced crew size); 
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• Enhanced precision: Automation allows more precise guidance and 
navigation, enhanced vehicle position control, and better energy 
management; 

• Enhanced safety: Automation enhances safety by providing for the rapid 
detection and actuation of emergency systems beyond the performance 
capabilities of the crew. 

• Economy of cockpit space and enhanced information display: The glass 
cockpit has allowed increased information integration while also affording 
new information display methods and simplifying crew operations (e.g., 
number of procedures and procedure steps). 

• Reduced crew workload: Automation reduced workload such that the 
flight crew could be reduced from three to two. Automation also removed 
crew responsibility for many tedious, time-consuming, and potentially 
interfering) tasks (e.g., auto-tuning radios). 

These enhancements, however, may have been accrued at a price. With increased automation, 
significant complexity has also been introduced into crew/automation interaction that has been 
implicated in a number of aircraft incidents and accidents (see, for example, Wiener, 1988 and 
Special Report, 1995). A seminal report by Wiener & Curry (1980) foreshadowed 
crew/automation interaction problems. Concerns with pilot interaction with flight deck 
automation has prompted research (e.g., Wiener, 1989; Sarter & Woods, 1991, 1992a, 1992b; 
Rudisill, 1994, 1995, 2000) and an in-depth review of the situation (with recommendations) by 
the FAA (Human Factors Team, 1996). In addition, several researchers have proposed sets of 
“human-centered” guidelines and principles for the design of highly automated crewed systems 
(e.g., Bergeron & Hinton, 1985; Billings, 1991, 1997; Dwyer, 1994). 

This report will include an overview of the evolution of the “glass cockpit” and flight deck 
automation. Some accidents & incidents related to flight crew interaction with automation on 
the flight deck are described, followed by an exploration of crew/automation integration issues 
that have been identified within the aviation domain, which could have application to an RLV. 
Some example crew/automation integration guidelines are provided, as well as a description of 
planned work to develop guidelines for the design of crew/automated systems for consideration 
on the next generation RLV. 

Evolution of the Glass Cockpit and Flight Deck Automation 

For a detailed description of flight deck evolution, see Billings (1991, 1997). Early automated 
flight decks had simple electromechanical flight and navigation instruments, with a first 
generation autopilot and Flight Director (FD). Vehicle information was distributed across 
individual displays. The pilot had primary responsibility for manually controlling the vehicle 
and monitoring the flight profile with rudimentary computer support. Next generation aircraft 
provided Performance Management Systems (PMS) with some rudimentary autoflight modes 
and a basic auto-touchdown function. The FD was integrated with rudimentary computer-based 
navigation support. Some functions were grouped within a common Mode Control Panel (MCP) 
and first generation autothrottles and autobrakes appeared. 
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The next generation aircraft witnessed a major evolutionary step in automated capabilities, due 
to increased computer memory and processing speeds. Previously independent systems were 
integrated with autopilots to provide a “Flight Management System (FMS),” enabling automated 
control of the entire flight. New auto flight modes appeared and were integrated into a next 
generation MCP. Information was displayed on “glass.” The fully automated FMS had 
programmable navigation/flight profiles with supporting navigation databases using accurate 
Inertial Reference Systems (IRS) and integrated performance calculations (e.g., fuel usage). The 
crew interface was provided by a Primary Flight Display (PFD), an Electronic Flight 
Instrumentation System (EFIS), and a Map display for lateral navigation. Automated landing 
capabilities increased. 

Modern transport aircraft have (multiple) complex and refined FMS’s, with larger and more 
sophisticated navigation databases, new autoflight modes, GPS-based navigation, digital 
autothrottles, and enhanced MCP’s. Autopilots with three-axis control allow enhanced guidance 
and crosswind landing capabilities. “System automation” (e.g, EICAS, Engine Indication 
Caution and Alerting System) with associated system displays and crew support (e.g., electronic 
procedures) appeared. The most recent aircraft have taken the next step with the introduction of 
automated failure mode handling. Sophisticated “fly-by-wire” control systems appeared, and 
some aircraft introduced active “envelope protection.” 

Crew/Automation Interaction Accidents & Incidents in the Aviation Domain 

Following is a brief description of a sample of incidents and accidents involving flight crew 
interaction with the automation on their aircraft. These examples are indicative of the types of 
problems that have been associated with the progressive introduction and use of automation on 
commercial transport flight decks. 

• “Strong and silent” automation, feedback, and information display. Automation has been 
called “strong and silent” in that it has significant capability to control the vehicle, but often 
provides little feedback to the crew concerning its present state and its operation. For example, 
in 1985, a China Airlines flight crew lost power in one engine during automated flight of a 
Boeing B747. The automation compensated for failing engine performance until its control 
limits were reached, at which point the automation failed and the aircraft went into an 
uncontrolled dive. The pilot was ultimately able to disengage the automation and recover the 
aircraft. The automation essentially masked the approaching onset of its control limits and the 
impending loss of control of the vehicle. 

In 1990, a British Midland Airways flight crew flying a B737-400 throttled back engine No. 2 in 
response to significant engine vibration, noise, and shuddering. However, engine No. 1 was on 
fire (difficult to discern from the re-designed glass “engine display,” particularly given the 
emergency circumstances); the engine suffered loss of thrust on final approach and crashed with 
significant fatalities. The accident investigation board questioned the methods used to evaluate 
and certify the new engine display, which was later improved by the manufacturer. 
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• Pilots as “system monitors” and crew over-confidence in automation capabilities. The pilot’s 
role has changed with automation, from “direct controller” to “system monitor.” At times, pilots 
have become complacent and have over-depended on their automation. 

In 1988, at the Habsheim airshow, an Air France flight crew was demonstrating the “low, slow 
flyover” capabilities of the Airbus A320. The aircraft lost energy and flew into the trees, killing 
all persons on board. The crew was confident of the automated “envelope protection” features of 
the aircraft. 

In 1996, an American Airlines B757 crashed in Cali, Colombia, killing all onboard. There were 
a number of underlying causes for this accident, many of which related to the automation and the 
flight crew’s training. The root causes of this accident included: 

• inadequacy of the navigational database used by the automated FMC; 

• the flight crew’s failure to maintain navigation situation awareness; 

• the flight crew’s misprogramming of a navigational waypoint; 

• crew task overload caused by unexpected runway changes (and the task load 
associated with re-programming the FMC); 

• crew training that emphasized automation use at the expense of maintaining crew 
manual control and navigation skills; and 

• language difficulties. 

As Phillips (1996) noted, this accident was, “a textbook case of pilots depending on automation 
to solve a problem rather than taking manual control... [The vehicle’s] computer did exactly 
what it was told to do.” As a result of this accident, the airline changed its policy with regard to 
crew use of automation and has followed other airlines in training its pilots to “turn off’ the 
automation and rely on their manual skills during an in-flight anomaly. 

• Crew interaction with complex automated flight modes. Automated flight modes have 
become increasingly sophisticated and complex. Crew mode confusion underlies a number of 
incidents and accidents. 

In 1992, an A320 crashed on final approach to Strasbourg, France airport, killing 87 of the 
passengers and crew. On investigation, it was determined that the autoflight system was set to 
the Vertical Speed (V/S) mode rather than the typical Flight Path Angle (FPA) mode. The 
display read, “3.3”; when in V/S mode, this indicates a descent rate of 3,300 feet per minute on 
final approach (four times the published descent rate) rather than a descent angle of 3.3 degrees 
in FPA mode (translating into a descent rate of about 1,000 feet per minute). It was a night flight 
through poor weather and, again, late instructions from ATC required the pilots to re-program 
their FMC, increasing their workload beyond a level they could handle safely. Apparently a 
similar incident had occurred on approach into San Diego airport in 1990, but the aircraft’s 
Ground Proximity Warning System (GPWS), not present on the Strasbourg flight, warned the 
pilots in time to disengage the automation and take manual control of the aircraft. As a result of 
the Strasbourg accident, the manufacturer redesigned the display panel to prevent such mode 
confusion. 
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There have also been accidents and incidents related to automation-commanded mode transitions 
(i.e., mode transitions not commanded by the crew) and the resulting changes in autoflight logic 
behavior. For example, an “uncommanded” (i.e., by crew) mode transition during a simulated 
engine failure on take-off contributed to the fatal crash of an A330 in Toulouse, France in 1994. 
During takeoff, the aircraft automatically transitioned to an automode; with no pitch authority 
limitations in this particular mode, the automation pitched the aircraft to 32 degrees nose high 
and maintained an excessive climb rate, causing the aircraft to lose airspeed and stall before the 
crew could disengage the automation and take manual control. The dynamic conditions in this 
situation were beyond the control logic capabilities of the particular autoflight mode, and the 
manufacturer has since changed the mode logic such that pitch authority is limited. 

Other autoflight mode accidents and incidents have been related to crew confusion with regard to 
the automated mode, perhaps exacerbated by non-standard mode disconnects and lack of 
automation feedback to the crew. In two cases (Moscow, 1991 and Nagoya, Japan, 1994), an 
autoflight mode commanded nose-up pitch while the pilot commanded nose-down pitch during 
an autopilot-coupled go-around. In the Moscow incident, the airplane went through a number of 
extreme pitch oscillations until the crew was able to disconnect the automation and gain control. 
In Nagoya, the crew inadvertently activated the go-around mode during a normal approach. The 
crew attempted to reacquire the glide slope by commanding nose down elevator, but this 
conflicted with the autoflight mode’s logic and pitch up commands. In addition, the automated 
stabilizer system had trimmed the aircraft to maximum nose-up, following its go-around logic 
(which may not have been clearly annunciated to the crew). The crew should have allowed the 
automated flight mode to control the aircraft, or should have completely disconnected the 
automation. That is, the situation was recoverable, but the crew, interacting with the automation 
(and in the presence of reduced feedback), put the aircraft into an unrecoverable position. An 
underlying issue relates to the mechanism enabling a pilot to disconnect the autoflight mode and 
regain manual control. The autopilot was designed to not disconnect using the standard control 
column force when in go-around mode below a specific altitude (for protection), and needed to 
be disconnected by an alternate mode; the crew may have believed they disconnected the 
autopilot and were manually controlling the aircraft when, in fact, the automation was still 
operating. Ultimately, the automated flight mode dominated and the aircraft pitched up, stalled 
and crashed. 

Crew/ Automation Interaction Issues & Problems 

As shown by the brief descriptions of automation-related incidents and accidents, with the 
benefits accrued by automation came a number of unexpected problems. This has generated 
research exploring crew interaction with automation. General categories of crew/automation 
interaction problems and issues are identified and briefly described below. 

• Safety and Crew Error 

Pilots maintain that automation has generally enhanced overall safety. Automation has freed the 
crew from many “mundane and time consuming” tasks, thereby allowing them more time for 
monitoring and decision making. However, automation may also lend a false sense of security. 
The majority of aircraft accidents are still attributed to human error (approximately 70%); it has 
been assumed that automating functions removed the source of this error (i.e., the human crew), 
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although this assumption is now in debate. More likely, automation relocated, rather than 
reduced, crew error (for example, crew must still monitor the automated systems, so automation 
generally does not operate without some crew input and interaction). Automation may have 
decreased some forms of crew error while creating opportunities for new error types. And these 
new error types may be more serious, since (1) the automation can often quietly compensate, 
then fail at the boundaries of the problem, from which it is more difficult to recover (and, in fact, 
may be unrecoverable at this point), and (2) crew may be “out-of-the-control loop” while 
automation is in command, making it more difficult for them to become sufficiently involved 
quickly enough to effect a recovery. 

• The Pilot as System Monitor 

The role of the crew on the flight deck has changed from “direct (manual) controller” to “system 
monitor and supervisor.” The crew must be supported in this role, especially if automation is 
“opaque” with regard to its state. “Silent” automation is more difficult to monitor and more 
difficult to recover from when it fails. Norman (1989) maintains that the primary problem with 
crew interaction with automation is lack of feedback and poor human/automation interaction. 

Some pilots report discomfort with a monitoring role: they are given responsibility for the 
flight/mission, but essentially give control to a silent and powerful controller. Automation 
technology should be viewed as a tool to be used by the crew as they require. Also, pilots report 
that automation requires more self-discipline — it is easy to depend on the automation and lose 
sight of the vehicle, becoming a “spectator” while automation does its job, rather than the vehicle 
commander. As evidenced by “Controlled Flight Into Terrain” (CFIT) accidents, a non-human 
computer controller will fly an aircraft into a mountain if it is instructed (i.e., programmed) to do 
so, with little regard to its “personal safety.” 

• Automation Complexity and Modes 

Automated systems have become quite complex and often the complexity has been coupled with 
little feedback about the actual state of the automated system. Pilots are generally positive about 
their automation, reporting that automation “allows them to concentrate on the real world outside 
the vehicle.” They particularly appreciate automated navigation support. But there is also a 
sense of “over-automation,” that automation technology was unnecessarily included on the flight 
deck, with little consideration of an actual requirement for it. 

One particular problem with automation complexity relates to “autoflight modes.” Multiple 
complex flight modes have, at times, reduced crew mode and situation awareness and 
understanding of automation and the energy state of the vehicle. Wiener (1989) established the 
“what’s it doing now?” syndrome, indicating the complexity of human/automation interaction. 
He reported that the most common questions pilots ask with regard to flight deck automation are: 
“What’s it doing now?”, “Why did it do that?”, and “What will it do next?” 

Exacerbating the mode complexity problem are “uncommanded mode changes” (i.e., 
automation, rather than crew, changing the flight mode with little or no annunciation), that 
effectively and silently change the control logic operating at the time, couched within a 
framework of little or no feedback about the automation’s activities. Mode problems have 
generated a significant amount of research, most notably work by Sarter and Woods (see, for 
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example, Sarter & Woods, 1991, 1992a, 1992b). From an automation survey they conducted, the 
authors reported that a significant number of pilots experience “FMS surprises” and do not 
understand all of the FMS modes and functions, even after one year of flight experience. These 
“surprises” were reported with such automated functions as vertical navigation logic, data entry, 
infrequently used features & modes, the FD, data propagation, and partial system failures. 

• Distancing 

Automation has placed a “layer” between the crew and the physical vehicle; that is, the crew no 
longer effects changes on the vehicle directly, but controls the vehicle “through” the automation. 
Pilots report feeling “isolated” and “distanced” from the physical vehicle and its energy state. 
Layering can make it more difficult to maintain situation awareness, it may foster a “crew out-of- 
the-loop” situation, and make it more difficult for the crew to anticipate vehicle behavior. 

• Command and Authority 

The increasing capabilities of automation have at times produced a situation where it is unclear 
“who is in charge.” Decisions (made, essentially, by the designer of the automation) can be 
implemented without crew consent and restrictions on crew capabilities can be instituted (e.g., 
“automated envelope protection” actively restricts the flight crew from performing flight 
maneuvers considered outside the operating envelope of an aircraft, even during an emergency). 
In addition, some pilots have noted that automation effectively alters command structure and 
“muddies” command authority by allowing either crewmember to manage the flight through the 
powerful FMS. 


• Crew Interaction & Cockpit Resource Management 

The visual nature of automation increases the need for crew communication and cooperation; 
flight decisions are made and programmed into the FMC but are not necessarily reflected in the 
displayed information, effectively removing one crewmember from the “decision loop.” 
Automation requires crew discipline (with regard to communication) and new operating 
procedures: at times, pilots are left to operate highly computerized equipment with procedures 
designed for electromechanical instruments. 

• Crew Workload 

With the glass cockpit, an “automation paradox” appeared (Wiener, 1989): automation reduces 
workload in low workload flight phases (e.g., cruise), but often increases workload during high 
workload flight phase (e.g., approach and landing). This increased workload is primarily caused 
by difficulties associated with interacting with the automation through the crew interface, that is, 
programming the FMS. This is especially true if there are changes in the flight plan that must be 
effected while controlling the vehicle. Workload also may significantly increase during an 
abnormal or emergency situation. In addition, automation has reduced manual workload, but has 
increased “cognitive” workload (e.g., planning and monitoring) and has introduced an “interface 
management task” in addition to the pilot tasks of “aviate, navigate, communicate.” Pilots report 
that it is often easier to turn off the automation and control the vehicle manually than to 
reprogram the automation during high workload situations. 
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• Display and Control Design 

The “glass cockpit” provides significant enhancements to the display of information to the flight 
crew. In particular, (1) integration of information onto a single Primary Flight Display 
(PFD)/Electronic Flight Instrumentation System (EFIS) display and (2) display of lateral 
navigation information on a “Map Display,” has significantly enhanced crew operations. But the 
glass cockpit also created new opportunities for clutter and the different organization of 
information may have also altered well-learned scan patterns; the new displays “take some 
getting used to” (e.g., reading an airspeed and altimeter “strip”). 

Automated controls are also well received, with “fly-by-wire” control systems highly regarded. 
However, one area of concern has emerged: some pilots believe that the lack of back-driving and 
lack of cross-coupling of some control systems removes a significant type of feedback that crew 
uses to maintain situation awareness of the vehicle. In addition, some implementations of 
automated control have “smoothed the boundaries,” effectively removing the “seat of the pants” 
feel that pilots use. 

• Fatigue, Stress, Complacency, & Boredom 

Automation generally reduces fatigue and stress. But pilots also report that they’ve observed an 
over-reliance on the automation, where they become complacent and can be lulled into a “false 
sense of security.” This appears to be particularly true with less experienced pilots, who may 
feel more comfortable depending on the computer to the point where they may “fixate” on the 
automation. Boredom associated with complacency may reduce their situation awareness and 
their ability to intervene during an emergency. This problem may be reduced by training, 
experience, and operating procedures that dictate decreased reliance on automated support and 
regular cross-checking of raw data. 

• Loss of Manual Skills 

Some pilots report degradation of, and decreased confidence in, their manual control skills with 
significant automation use, decreasing safety when crew is used as the “back up” to a failed 
automated control system. Automation has not changed the fundamentals of airmanship; 
understanding this, some pilots regularly turn off the automation and fly manually to maintain 
their skills. 


• Crew Training and the Automation “Mental Model” 

Transitioning to a glass cockpit is often difficult; this “new way of flying” requires significant 
learning and a significant change in the pilot’s “mental model” concerning how the vehicle is 
operated. Training needs to provide sufficient vehicle and system knowledge to allow crews to 
understand the automation and solve problems when they arise. They need hands-on practice to 
feel comfortable programming the automated systems (and efficiently re-programming if the 
situation arises). How and when to use the automation effectively should be emphasized. And 
training needs to be coupled with procedures and an “automation operating philosophy” that 
accounts for the difficulties described here. 

• Level of Capability 

At its present level of capability, automation is able to perform numerous tasks formerly only 
performed by human crew, with high levels of precision (particularly, navigation and flight 
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control tasks). But automation is not yet capable enough to completely replace a human 
crewmember; there are flight situations (e.g., significant crosswinds) where an automated 
controller cannot operate. In particular, automation cannot yet perform well under those 
circumstances where humans excel, such as operating under uncertainty, with little or no 
information, and operating under new (i.e., untrained or “unprogrammed”) circumstances. For 
the near future, combined human/automation systems are to be expected. 

Space Transportation & Human-Centered Automation 

This aviation experience base provides a set of “lessons learned” that may be applied to the 
design of future human-rated Space Transportation Systems. To enhance crew effectiveness and 
to prevent these types of crew/automation problems in a next generation RLV, a human-centered 
approach to automation design must be followed. This includes developing and following a set 
of human-centered principles, rules, and standards that define, and guide the design of, 
crew/automation systems. The potential problems defined in this report have implications both 
for design of the crew/vehicle interface throughout the vehicle and for crew operations (e.g., 
training, operating procedures, flight rules); therefore, design principles and guidelines should be 
defined for all of these areas. 

From a review of the aviation experience base, an initial set of categories for crew/automation 
design principles and guidelines for space transportation systems has been developed (see 

Appendix A). These principles and guidelines will address such factors as: philosophy of 

automation use; crew vs. automation roles and responsibilities; the crew interface to automation; 
automation feedback; automated flight management; automated modes; crew workload; 
confidence and complacency; predictability, reliability, and trust; automation training content 
and approach; cockpit operations and crew coordination; personal factors; failures and off- 
nominal situations; and crew skills maintenance. 

As a beginning point, principles and guidelines for the design of human/automation systems 
derived from aviation experience have been defined by a number of researchers and can be 

adapted to the space transportation domain. For example, Wiener & Curry (1980) provided 

guidelines for the support of control and monitoring tasks. Billings (1991, 1997) published a 
number of guidelines and principles for the design of human/automated systems in the areas of 
control, information, and management automation. He maintains that, ultimately, human- 
centered automation is accountable, subordinate, predictable, adaptable, comprehensible, simple, 
flexible, dependable, informative, error resistant, and error tolerant. In addition, Billings 
provided high level guidelines dictating interactions within a combined human/automation 
system (e.g., the human operator must be in command; automated systems must be predictable; 
and functions should be automated only if there is a good reason for doing so.) 

Dwyer (1994) published general and specific guidelines for designing the automated system 
(operational and adaptive capabilities), system interface and operational considerations (controls, 
displays, and formats; information), and artificially intelligent processing. Rudisill (1995) 
described guidelines for design (e.g., displays, controls), for enhancing crew understanding and 
automation use, for enhancing crew operations with automation, and for managing crew personal 
factors (e.g., complacency). 
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A design philosophy and principles for human/automation integration were provided by Palmer, 
Rogers, Press, Latorella, and Abbott (1995). Their crew-centered design philosophy is defined 
by a set of over-riding philosophy statements, and a set of design principles are organized by 
consideration of the crewmember as a team member, as a commander of the mission, as an 
individual operator, and as a vehicle occupant. The FAA’s Human Factors Team, in their review 
of the interfaces between flight crews and modern flight decks (1996) stated a number of guiding 
design principles and recommendations for the design of human/automation systems. 

Conclusions 

The next generation human-rated RLVs will witness significant increases in automation 
technologies. Typical operations will involve significant crew interaction with this automation. 
The space transportation community would be served in developing principles, guidelines and 
standards, based on lessons learned from the aviation community, to guide the design and use of 
automation on these types of vehicles. In providing information for this task, (1) an initial 
review of the aviation automation research literature has been conducted, (2) crew/automation 
integration categories have been identified, (3) an outline for principles, guidelines, and 
standards has been generated, and (4) a project overview and roadmap is under development 
within the NASA Integrated Space Transportation Project Plan for guiding this effort. 
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Appendix A 


Outline 

Principles, Guidelines, and Standards for Crew/ Automation Integration 
In a Space Transportation System 

Philosophy of Automation Use 

Crew role & automation role 

Automation technology 

Crew / automation integration and interaction 

Automation and the Crew Interface 
Displays and instruments 

Information density, relevance, and “truthfulness" 

Automation feedback to the crew 
Making failures obvious and understandable 
Mode errors 

Integration and standardization 
System response time 
Crew information input 

Flight Management Automation (FMA) 

Predictability of automation operation 
Complexity of interaction 
Flight Management programming 
“Correctness" and the crew mental model 
Specific problems with FMA 
Pre-occupation 

Detecting and understanding system problems 
Distancing through technology layers 

Crew Workload and Automation 
During failures 

During emergencies and off-nominal operations 
Relative to flight phase 
Relative to crew roles 
Relative to flight conditions 

Crew Confidence in Automation 
Level of trust and reliance 
Technology maturity & reliability automation 
Risk Perception 

Training and Automation 

Amount of automation-specific training 

Depth of training 



Training content 

Approach to automation training 

Learning curve with automation 

Recurrent training & skill maintenance 

Handling skills 

Airmanship 

Scan pattern 

Situation and position awareness 
Cockpit Operations Management 

Cockpit management, crew coordination, division of labor 

Vigilance and monitoring 

Cockpit crew communication 

Interacting and coordinating with MCC 

Standard operating procedures and policies for automation use 

Supporting documentation 

Crew Personal Factors 

Experience 

Self-discipline 

Stress 

Fatigue 
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